home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c / 759 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  4.0 KB
  1. Path: tbj.dec.com!diamond
  2. From: diamond@tbj.dec.com (Norman Diamond)
  3. Newsgroups: comp.std.c
  4. Subject: Re: valueless return statement in non-void function
  5. Date: 18 Apr 1996 01:46:49 GMT
  6. Organization: Digital Equipment Corporation Japan , Tokyo
  7. Message-ID: <4l46u9$r68@usenet.pa.dec.com>
  8. References: <829573502snz@wbriscoe.demon.co.uk>
  9. Reply-To: diamond@tbj.dec.com (Norman Diamond)
  10. NNTP-Posting-Host: jit533.tbj.dec.com
  11.  
  12. In article <829573502snz@wbriscoe.demon.co.uk>, walter briscoe <walter@wbriscoe.demon.co.uk> writes:
  13. >I recently had trouble moving some K&R code to ISO C.
  14. >Specifically, a function without a return statement was used to return a
  15. >value with an implicit return at the } terminating the function.
  16.  
  17. This was not K&R code.  In K&R code, there was no "void" type so all
  18. functions had to have some return type (defaulting to int) but just didn't
  19. have to return a value if no return value was expected.  In K&R code, if a
  20. value was not returned by a return statement, then no value was returned.
  21. There was no implicit return value at the } terminating the function.
  22.  
  23. >Section 6.6.6.4 of ANSI/ISO 9899-1990 contains the Semantic restriction
  24. >> If a return statement without an expression is executed, and the value
  25. >> of the function call is used by the caller, the behavior is undefined.
  26. >> [...]  Reaching the } that terminates the function is equivalent to
  27. >> executing a return statement without an expression.
  28. >
  29. >I am surprised/irritated that the undefined behavior is in the caller
  30. >rather than the called function.
  31.  
  32. At the time of executing the called function, if the implementation can
  33. determine that the caller will necessarily attempt to use a value which
  34. the called function is not returning, then the implementation is free
  35. to exhibit undefined behavior at that point.  An example of undefined
  36. behavior could be to continue executing what the program specifies until
  37. the point where the caller attempts to use a value which the called
  38. function did not return, and then take some unpredictable action.
  39. So if you get the change you're asking for, how will you even know?
  40.  
  41. >I would like the next version of the standard to have an additional
  42. >constraint:
  43. >A return statement without an expression shall only appear in a function
  44. >whose return type is void.
  45.  
  46. Don't forget to add:
  47.  The statement preceding the } that terminates a function whose return
  48.  type is not void shall be one of these forms:
  49.  o   a return statement,
  50.  o   a goto statement,
  51.  o   an if statement with else clause in which each sub-statement is
  52.       one of these forms, or
  53.  o   a switch statement in which the sub-statement contains a
  54.       sub-sub-statement with the label label default and every
  55.       sub-sub-statement is one of these forms, or
  56.  o   a compound statement in which the last sub-statement is one
  57.       of these forms.
  58.  
  59. >The obvious objection to such a statement is that it conflicts with
  60. >prior art.  I would answer that by making the implicit type of
  61. >declarations void rather than int.  That would allow less unreasonable
  62. >prior art to port without complaint.
  63.  
  64. You mean because less unreasonable K&R code always used the redundant
  65. type specifier "int" to declare functions that returned int when they
  66. really intended to return int?  As it happens, I agree with you that this
  67. kind of coding style is good practice for readability and maintainability,
  68. and resent having to fight against a language in order to practice such
  69. noble ideals.  However, your real request is to use a language other than
  70. C.  Again I agree, most programs should not use C.
  71.  
  72. >I would have implicitly typed declarations deprecated in the next
  73. >revision of the standard to facilitate their removal by a further revision.
  74.  
  75. Put it in a standard for a different language.  You probably know a dozen
  76. that have this feature.
  77. --
  78.  <<  If this were the company's opinion, I would not be allowed to post it.  >>
  79. "I paid money for this car, I pay taxes for vehicle registration and a driver's
  80. license, so I can drive in any lane I want, and no innocent victim gets to call
  81. the cops just 'cause the lane's not goin' the same direction as me" - J Spammer
  82.